其他
从制作九转大肠来谈起 | GreptimeDB 如何提高多步操作的容错能力
点击蓝字,关注我们
Procedure 是 GreptimeDB 最近正在开发中的一个新特性,通过引入 Procedure 框架,来帮助记录数据库中多步操作的进度以及对该操作自动进行失败重试,保证其能执行完成。
这篇文章将简单介绍下 Procedure 框架是什么,以及我们实现 Procedure 的方式和未来规划。
为什么需要 Procedure
Region
。我们使用以下组件记录系统中存在的表和每个表的元数据CatalogManager
负责记录系统中存在的所有表• TableManifest
负责记录表的元数据,包括表结构,一张表有多少个 Region
等信息• RegionManifest
负责记录 Region
的元数据,如 Region
的结构,包含的数据文件等CREATE TABLE
为例:建表的时候,数据库需要先后执行以下动作为每个
Region
创建RegionManifest
并持久化Region
的元数据创建
TableManifest
并写入表的元数据往
CatalogManager
中写入表的记录
TableManifest
中已经写入了表的元数据,但是 CatalogManager
中却没有关于这张表的记录。当然,实际上还存在其他比建表更复杂的情况,比如 DROP TABLE
。Procedure 框架
Procedure
ProcedureId
标识自身• Procedure 实际上类似一个状态机,每执行一步,就会进入下一个状态,直到状态机结束• 需要能够序列化自己当前执行的进度• 每一步都需要做到幂等,使得每一步都可以重试ProcedureStore
/procedures/{PROCEDURE_ID}_000001.step
/procedures/{PROCEDURE_ID}_000002.step
/procedures/{PROCEDURE_ID}_000003.commit
ProcedureManager
解决建表遇到的问题
Region
,创建表,将表注册到 CatalogManager
。在每一步里,我们需要注意实现的幂等性。例如如果 Region
已经创建好了则无需重复创建。ProcedureId
就是这个菜品的流水号• 每个菜品都有清单追踪制作过程中的每个环节,而 ProcedureStore 就是用来记录进度的表单• ProcedureManager 就像是整个后厨的流水线,根据订单不断地制作菜品,更新表单后续工作
ALTER TABLE
和 DROP TABLE
等• 实现分布式 Procedure 框架。在分布式环境下,我们计划将 Procedure 框架运行在整个集群的“大脑” Metasrv 上,由 Metasrv 调度 Procedure 的执行• 目前 GreptimeDB 建表的处理流程在单机和分布式下各不相同,也为实现者带来负担。我们将探索通过 Procedure 框架统一分布式和单机的处理流程• 支持 Procedure 的回滚操作。HBase 的 ProcedureV2 框架还支持回滚,但目前 GreptimeDB 支持回滚 Procedure 的优先级并不高,因此暂时没有实现这一功能总结
参考
[2]https://accumulo.apache.org/1.8/accumulo_user_manual.html#_fault_tolerant_executor_fate
[3]https://github.com/GreptimeTeam/greptimedb/blob/0ffa628c22fa1a34e244b33afd6fe85585b8824a/docs/rfcs/2023-01-03-procedure-framework.md
[4]https://github.com/GreptimeTeam/greptimedb/issues/286
[5]https://github.com/GreptimeTeam/greptimedb/pull/836
[6]https://developer.mozilla.org/zh-CN/docs/Glossary/Idempotent
[7]https://docs.greptime.com/developer-guide/meta/overview
关于 Greptime
● GreptimeDB v0.1 发布|原生支持 Python, PromQL 和对象存储
● GreptimeCloud 内测申请开放|浅谈数据库云服务值得关注的 4 大体验